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Dependency analysis is a technique to identify and determine data dependencies between service 
protocols. Protocols evolving concurrently in the service composition need to impose an order in 
their execution if there exist data dependencies. In this work, we describe a model to formalise 
context-aware service protocols. We also present a composition language to handle dynamically the 
concurrent execution of protocols. This language addresses data dependency issues among several 
protocols concurrently executed on the same user device, using mechanisms based on data semantic 
matching. Our approach aims at assisting the user in establishing priorities between these dependen- 
cies, avoiding the occurrence of deadlock situations. Nevertheless, this process is error-prone, since 
it requires human intervention. Therefore, we also propose verification techniques to automatically 
detect possible inconsistencies specified by the user while building the data dependency set. Our 
approach is supported by a prototype tool we have implemented. 



1 Introduction 



Service composition is a crucial paradigm in Service Oriented Computing (SOC), since it allows to build 
systems as a composition of pre-existing software entities, COTS {Commercial-Off-The-Shelf applica- 
tions) rather than programming applications from scratch. An important issue of service composition 
is to find out services with capabilities compatible to the user requirements in order to compose them 
correctly. In a traditional distributed environment, in which all the requests are served in the same way, 
service composition is straightforward. The introduction of Web-enabled hand-held devices has created 
the necessity of a more context oriented composition in which the produced response is aware of certain 
user and environment information on the requesting client. Thus, context-awareness enables a new class 
of applications in mobile and pervasive computing, providing relevant information to users. Therefore, 
context information can help users to find nearby services, to decide the best service to use, to control 
reaction of systems depending on certain situations, and so on. 

Services are accessed thiough their public interfaces that may distinguish four interoperability lev- 
els in : (i) the signature level provides operation names, type of arguments and return values, (ii) the 
behavioural or protocol level specifies the order in which the service messages are exchanged with its 
environment, (iii) the service level deals with non-functional properties Uke temporal requirements, re- 
sources, security, etc., and (iv) the semantic level is concerned about service functional specifications 
(i.e., what the service actually does). In industrial platforms, service interfaces are usually specified us- 
ing signatures (e.g., WSDIJJ), but some recent research works |[T]|6j[TT]|27l have extended interfaces with 
a behavioural description or protocol. Protocols are essential because erroneous executions or deadlock 
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situations may occur if the designer does not take them into account while composing clients and ser- 
vices |[T8ll24ll . In this way, service protocols evolving concurrently in a composition need to impose an 
order in their execution if there exist data dependencies. Dependency analysis is a technique to identify 
and determine data dependencies between service protocols. To the best of our knowledge, not many 
works have tackled the handling of concurrent interactions of service protocols through dependency 
analysis ||51[l0l[Il[ni|26l. 

In this work, we focus on systems that consist of client^ (users with a mobile device such as a PDA 
or a smart phone) and services modelled with interfaces constituted by context information, a signature, 
and a protocol description (taking conditions into account). We also consider a semantic representation 
of service instead of only a syntactic one. We use OWL-S ontologie^ to capture the semantic description 
of services by means of relationships between concepts within a specific domain. In order to address the 
concurrency in the service composition in these systems, we first formalise a model for context-aware 
clients and service protocols. Second, we propose an approach to handle dynamically the concurrent 
execution of context-aware service protocols on the same user device, using mechanisms based on data 
semantic matching. Our approach aims at assisting the user in establishing priorities between these de- 
pendencies, avoiding the occurrence of deadlock situations. Constraints on the concurrent execution can 
be specified using a composition language which defines operators for executing a sequence of protocols, 
a non-deterministic choice between protocols, and for controlling the data dependencies existing among 
several protocols executed at the client level at the same time. In addition, since this process requires 
human intervention (error-prone), we use analysis techniques to automatically verify the correct execu- 
tion order of the protocols with respect to the built data dependency sets. Our approach is supported by 
a prototype tool we have implemented. To evaluate the benefits of our approach, we have applied it to 
different case studies. We analyse the experimental results obtained either with manual or interactive 
specification of data dependencies and their con^esponding execution priorities. 

The rest of this paper is structured as follows. Section|2]presents our model formalising context-aware 
clients and service protocols. In Section [3l we introduce a case study we use throughout the paper for 
illustration purposes. Section|4] presents the handling of concurrent interactions of context-aware service 
protocols. Section [5] describes the ConTexTive prototype tool that implements our approach, and shows 
some experimental results. Section [6] compares our approach to related works. Finally, Section |7] ends 
the paper with some concluding remarks. 



2 Context- Aware Service Model 

2.1 Interface Model 

Our model describes client and service interfaces using context profiles, signatures and protocols. Con- 
text profiles define information which may change according to client preferences and service environ- 
ment. Signatures correspond to operations profiles. Protocols are represented using transition systems. 

A context is defined as "the information that can be used to characterise the situation of an entity. 
An entity is a person, place, or object that is considered relevant to interaction between a user and an 
application including the user and application themselves" II13II . Context information can be represented 
in different ways and can be classified in four main categories |[T6l : (i) user context: role, preferences, 
language, calendar, social situation or privileges, (ii) device/computing context: network connectivity. 



^In the sequel, we use client as general term covering both client and user with a mobile device. 
^http://www.daml.org/services/owl-s/ 
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device capabilities or server load, (iii) time context: current time, day, month or year, and (iv) physical 
context: location, weather or temperature. For our purpose, we only need a simple representation where 
contexts are defined by context attributes with associated values. In addition, we differentiate between 
static context attributes (e.g., role, preferences, day, ...) and dynamic ones {e.g., network connectivity, 
current time, location, privileges, ...). Dynamic attributes can change continuously at run-time, so they 
have to be dynamically evaluated during the service composition. Last, both clients and services are 
characterised by public (e.g., weather, temperature, ...) and private {e.g., personal data, bandwidth, ...) 
context attributes. Thus, we represent the service context information by using a context profile, which is 
a set of tuples {CA,CV,CK,CT), where: CA is a context attribute or simply context with its corresponding 
value CV , CK determines if CA is static or dynamic, and CT indicates if CA is public or private {e.g., 
{priv, Guest, dynamic, public), where priv is a public and dynamic context which corresponds to user 
privileges with Guest as value). 

A signature corresponds to a set of operation profiles. This set is a disjoint union of provided and 
required operations. An operation profile is the name of an operation, together with its argument types 
(input/output parameters) and its return type. 

A protocol is represented using a Labelled Transition System (LTS) extended with value passing, 
context variables and conditions, that we caU Context-Aware Symbolic Transition System (CA-STS). 
Conditions specify how applications should react {e.g., to context changes). We take advantage of using 
ontologies to determine the relationship among the different concepts that belong to a domain. Let us 
introduce the notion of variable, expression, and label required by our CA-STS protocol. We consider 
two kinds of variables, those representing regular variables or static context attributes, and variables 
corresponding to dynamic context attributes (named context variables). In order to distinguish between 
them, we will mark the context variables with the symbol "~" over the specific variable. An expression is 
defined as a variable or a term constructed with a function symbol / (an identifier) applied to a sequence 
of expressions, / € f{F\ ,... ,Fn), Fi being expressions. 

Definition 1 (CA-STS label) A label corresponding to a transition of a CA-STS is either an internal 
action z (tau) or a tuple {B,M,D,F) representing an event, where: B is a condition (represented by 
a boolean expression), M is the operation name, D is the direction of operations (! and ? represent 
emission and reception, respectively), and F is a list of expressions if the operation corresponds to an 
emission, or a list of variables if the operation is a reception. 

Definition 2 (CA-STS Protocol) A Context-Aware Symbolic Transition System (CA-STS) Protocol is a 
tuple {A,S,I,Fc,T), where: A is an alphabet which corresponds to the set of CA-STS labels associated 
to transitions, S is a set of states, I ^ S is the initial state, f c C 5 are correct final states (deadlock final 
states are not considered), and T QS xAx S is the transition function whose elements {s\,a,S2) S T are 
usually denoted by s\ — > S2. 

Finally, a CA-STS interface is constituted by a tuple {CP,SI,P), where: CP is a context profile, and 
SI is the signature corresponding to a CA-STS protocol P. Both clients and services consist of a set of 
interfaces. We assume they have several protocols with their corresponding signatures, and a context 
profile for each one. For instance, let us consider a client with two different protocols P^, and P^^. This 
client consists of two interfaces such as: 7^, = {CPc^,SIc, ,Pc-, ) and 7^2 = {CPc2,SIc-,,Pc2)- 

We adopt a synchronous and binary communication model (see Section l2!2] for more details). Clients 
can execute several protocols simultaneously (concurrent interactions). Client and service protocols can 
be instantiated several times. At the user level, client and service interfaces can be specified using: 
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(i) context information into XML files for context profiles, (ii) WSDL for signatures, and (iii) busi- 
ness processes defined in industrial platforms, such as Abstract BPEL (ABPEL) IH or WF workflows 
(AWF) tlZJI, for protocols. Here, we assume context information is inferred by means of the client re- 
quests (HTTP header of SOAP messages), and we consider processes (clients and services) implemented 
as business processes which provide the WSDL and protocol descriptions. 

2.2 Operational Semantics of CA-STS 

We formalise first the operational semantics of one CA-STS service, and second of n CA-STS services. 
Next, we use a pair {s,E) to represent an active state s £ S and an environment E. An environment is a 
set of pairs (x,v) where jc is a variable, and v is the corresponding value of x (it can be also represented 
by E{x)). The function type returns the type of a variable. We use boolean expressions b to describe 
CA-STS conditions. Regular and context variables are evaluated in emissions and receptions (by con- 
sidering the cun^ent value of the context, e.g., the cun^ent date), respectively. Therefore, two evaluation 
functions ai^e used in order to evaluate expressions into an environment: (i) ev evaluates regular variables 
or expressions, and (ii) evc evaluates context variables changing dynamically. We define ev as follows: 

^ \E(x) if X is a regular variable 
ev{E,x) = < 

I X ifx is a context variable 

ev{E,f{vi,. . . ,Vn)) = f{ev{E,vi),. . . ,ev{E,v„)) 

Function eVc is defined in a similar way to ev, but it only considers context variables. This is because 
we first apply ev in order to evaluate all the regular variables: 

eVc{E,x) =E{x) 

where x is a context variable. We also define an environment overloading operation "0" such that, given 
an environment E, E0 {x,v) denotes a new environment, where the value corresponding to x is v. 

We present in Figure[T]the semantics of one CA-STS (—>„), with three rules that formalise the mean- 
ing of each kind of CA-STS labels: internal actions T (INT), emissions (EM), and receptions (RFC); and 
one rule to consider the dynamic update of the environment according to the context changes at run-time 
(DYN). Note that w.rt. Definition [T] Z? € B is a condition, a € M is an operation name, and x G f and 
V £ F correspond to a list of variables and expressions, respectively. Condition b may contain regular 
and/or context variables and both of them must be evaluated in the environment of the source service 
(sender), because the decision is taken in the sender. However, evaluation of expressions v only affects 
regular variables (rule FM), since context variables will be evaluated in the target service (receiver) to 
consider the context values when the message is received (see rule COM in Figure|2l). We assume that the 
dynamic modification of the environment will be determined by different external elements depending 
on the type of context (e.g., user intervention, location update by means of a GPS, time or temperature 
update, and so on). Then, we model this situation by assuming a transition relation which indicates the 
environment update, denoted hy E -^ ^E', where E'{x) ^ E{x) only if x is a dynamic context variable. 

The operational semantics of n (n > 1) CA-STSs (— )-c) is formalised using two rules. A first syn- 
chronous communication rule (COM, Figure|2ll in which value-passing and variable substitutions rely on 
a late binding semantics 11211 and where the environment E is updated. A second independent evolution 
rule (INFt, Figure|2ll. A list of pairs {si,Ei) is represented by [asi,. . . ,as„]. Rule COM uses the function 
eVc to evaluate dynamically in the receiver the context changes related to the dynamic context attributes 
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(s-^s')eT eVc(ev(E,b),b)^true (s^^s')'ET evAev(E,b),b) = true 



{s,E) A„ (/,£) {s,E) ^^o {s',E) 

^sJ^s')eT ev,{ev{E,b),b)^true v' = ev{E,v) ^^^^ E ^ ,E' ^^^^^ 

{s,E) ^„ {s',E) i^^E) A„ {s,E') 

Figure 1: Operational Semantics of one CA-STS 

of the sender. Regular variables have been evaluated previously in the rule EM when the message is 
emitted. This dynamic evaluation handled in the operational semantics allows to model service protocols 
depending on context changes. Rule INE^: is executed in case of an internal service propagation that 
gives rise to either a state (related to the rule INT) or an environment (rule DYN) change. Thus, transi- 
tions — >c do not distinguish between internal evolutions coming from either internal actions in services 
or dynamic updates in the environment. 



ij e {!..«} / 7^ j {si,Ei) -^o {s'i,Ei) {sj,Ej) ^^„ {s'j,Ej) 
type{x) = type{v) E'j = Ej {x,eVc{Ej,v)) 

[asu- ■ ■ , {si,Ei),. . . , {sj,Ej),. . .,as„] -^c [asi,. . . , {s'i,Ei),. . . , (spE'j),. . .,as„] 

ie{l..n} {s„E,) ^o {s'.,E'-) 

[asi, . . . , {si,Ei),. . .,asn] Ac [asi,. . . , {s'i,E'-),. . . ,as„] 

Figure 2: Operational Semantics of n CA-STSs 



(COM) 



(INE,) 



3 Motivating Example 

For illustration purposes, we consider a road info system that consists of users travelling by cai^ on a 
road and using mobile devices (called Clients), and Info Services providing information requested by 
the Clients. Info Services contain information about routes, hotels, restaurants, gas stations, multimedia 
entertainment such as movies, music, images, shows, and so on, or museums. Some of these services are 
free {e.g., Route or Gas Station Services) and others have to be payed (e.g., Entertainment or Museum 
Services). For these latter ones the Client needs to check his/her bank account. 

For the sake of comprehension, we consider a reduced part of our case study. Let us suppose that a 
Client, before starting the trip, wants to plan a route. Afterwards he/she wants to perform at the same time 
the purchase of both a music album to listen during the trip, and a ticket for a museum located at his/her 
destination to visit that same day. Ideally, the first request must be satisfied by the nearest Route Service, 
which considers the context information related to the Client location loc (dynamic context attribute), and 
to the traffic and weather of the environment (dynamic attributes). The nearest Entertainment Service 
should manage the second request, by taking into account privileges priv (dynamic attribute) of the Client 
{e.g., if the Client has privileges of subscriber he/she will pay a reduced amount for an album), and its 
server load (dynamic attribute). The third request has to be replied by the Museum Service that also 
takes into account Client privileges priv, and the day to visit the museum (static attribute). This last 
request could also be replied by the Entertainment Service, since this service can handle the purchase of 
any show (museum, concert, cinema, etc) as well. We consider all the context attributes mentioned are 
public and in our scenario they have a default value, that in case of the dynamic ones may change. 
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This scenario requires to discover automatically the most appropriate services for each client's re- 
quest among the available services (running at the moment of each request) from the repository of Road 
Info Services. According to the dynamic nature of the context information, context changes at run-time 
may occur. Thus, for instance, once the Client has requested a route, when some changes in his/her 
dynamic context attributes (e.g., loc) occur, the Route Service situated along the Client's way must au- 
tomatically recompute the route according to the new context values (rule DYN, Figure [B. On the other 
hand, we focus on the concurrent executions of several protocols at run-time, that must be handled {e.g., 
the Client requesting concurrently a music album and a museum ticket). All these considerations make 
our approach appropriate to model this kind of systems and to handle the concurrent interactions of 
protocols. For the sake of simplicity, we suppose the available services from the repository are Route, 
Entertainment and Museum Services. In Figure [3l the interfaces of Client and Info Services are given 
for the scenario previously described. 



Client 



Context Profile 

loc (dynamic) 




Route Protocol (HC) 

lrci=reqRaJte '.destjoc 




irc2=getRoute ?route 




Museum Protocol (MC) 

^C2=St0p? 

imci=reqMuseurh ImuseunKprJv 
lmc3-priceMusem! ?m us eum, price 
lmc4=checkAicount!account 
lmc5=bankBilance ?credit 



Imc6=[balapce^price] lrrtis=[balance < 
buyMusedm Imuseum pfjcejcancel! 



Info Services 



Context Profile 

loc (dynamic) 

(raWc (dynamic; 

weather (dynamic) 



Route Service 



Entertainment Service 



Entertainment Service 
Protocol (ES) 

les!=setlterrKitem,pri v' 

werioad^ 
"excess'Jcancel! 

Ies3=[serveribad < "excess "] 
prioelten litem, price 



les4=checkAkcount?account 





l6S6=[credlt>price] 
purchasmtem litem 



Museum Service 
Protocol {/WS) 

lms!=setMuseum ?mus^m 

}ay="monday"] 
cancel I 
Ims3=[day <>"monday" JprheMuseum Imuseum, price 

©~~~^\ 

lms4=checkAccount?hccount 





Figure 3: CA-STS Protocols of Client and Info Services for our Scenario 



The Client has three interfaces corresponding to the three client's requests (Route, Music (Album) 
and Museum), which consist of three protocols {RC, AC and MC, respectively), each one with a context 
profile, and a signature. The latter one will be left implicit, yet it can be inferred from the typing of ar- 
guments (made explicit here) in CA-STS labels. On the other hand, each service (Route, Entertainment 
and Museum) has an interface with a context profile, a (implicit) signature and a protocol {RS, ES and 
MS, respectively). We assume RC should interact with RS, AC with ES, and MC with MS. It is worth 
mentioning that the ES protocol may be instantiated for communicating with different client's requests 
related to movies, music, images, shows and so on. Thus, ES could also manage the Client's Museum re- 
quest MC. Let us consider, e.g. , the label RC : /,-c, = reqRoute\dest,loc from the Client's Route protocol, 
where dest is a data term which indicates the destination requested for the route, and loc is a dynamic 
context attribute of the Client's Route context profile. The Route Service protocol T?^' receives the request 
through a label such as RS : /„i = setRout eldest , loc where dest and loc are variables. 

Figure |4] gives the domain ontology related to this road info system. We present the classes used in 
our scenario with their relationships. These classes represent concepts which may be either a context 
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attribute, an operation name, or an argument. This ontology has been generated using Protege 4.0.4J. 




( getRojte J 



Figure 4: Road Info System Ontology generated using Protege 4.0.2 



4 Handling Concurrent Interactions 

This section describes a composition language that allows to execute and handle concurrently interactions 
between a client and several services at the same time. Our language addresses data dependency issues 
that appear in the concurrent execution of client protocols, since all data received by a client are shared 
and can be accessed by several of his/her protocols. Therefore, our mechanism allows to maintain data 
consistency, even if a change occurs at run-time. We can also detect problems coming from the data 
dependencies, which would result in deadlocks during the execution of the protocols if not corrected. 

4.1 Composition Language 

In this section, we formalise a language to dynamically compose several protocols, with the following 
operators: sequence, choice and parallel dependency (or concurrency). 



4.1.1 Syntax 

A client can execute a sequence of the form P1.P2, where P\ and P2 are two protocols: "execute Pi and 
then P2". A non-deterministic choice P\ +P2 can be performed: "run Pi or P2". The concurrent execution 
of two protocols Pi , P2 is written Pi | \ldP2 '■ "execute Pi , P2 in parallel while respecting data dependencies 
specified in LD". LD is a set of label dependencies {{id : / > id' : /')}, where / an /' are labels, and id and 
id' are protocol identifiers prefixing the labels. LD represents dependencies between arguments involved 
in the labels of these two protocols. Symbol ">" indicates the order of execution in which labels must 
be executed {e.g., {p\ : I > p2 '■ I'), I is executed before /'), being / and /' the dominant and dominated 
labels, respectively. If more than two protocols ai^e executed concuiTcntly, then we will detect the data 
dependencies by pairs of protocols. Here is the syntax of the composition language: 

The goal of our composition language is to illustrate with a minimal expressiveness our service com- 
position approach. We could have also included for instance repetition operators such as P* (executes P 
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P ::= Pi -Pi sequence 

I Pi+Pi non-deterministic choice 
I ^1 1 \ldP2 parallel dependency 

several times) or P^ (executes P x times). Nevertheless, repetition can be achieved by launching manually 
several times the execution of P. 



4.1.2 Operational Semantics 

We formalise the operational semantics of the composition language. The rules presented in Figure [5] 
extend the operational semantics of our model to the operators previously considered. In SEQ2, Fc\ 
refers to the correct final states of the protocol Pi. Both + and \\id are commutative, therefore the 
symmetrical rules are omitted. Label / represents either the internal action t, an emission a\v, or a recep- 
tion alx. PLDl performs the concurrent execution of the protocols Pi and P2 w.r.t. a label dependency 
{p\ '■ I > P2 '■ I'), and removes the label dependencies which include / as first element from the label 
dependency set LD. PLD2 works as PLDl, but without removing label dependencies, since / appears in 
a loop in its protocol. Last, PLD3 executes a label which does not belong to the label dependency set. 

{si-,Ei) ^o{s\,Ex) {s2,E2) -^o {s'2,E2) siEFci {si,Ei) ^^ {s[,Ei) 



{si,Ei).{s2,E2) ->„ {s[,Ei).{s2,E2) {si,Ei).{s2,E2} -^„ {s2,E2) {si,Ei) + {s2,E2) ->„ {s\,Ei) 

(SEQl) (SEQ2) (NDCH) 

{si,Ei) \ {s[,Ei} {pi:l>P2-l')eLD (suEi) \ {s[,Ei) {pi : I > Pi'- 1') e LD 

LD' = remove (I, LD) {si,Ei) -/^o *(.?!, £1) i^uEi) ->„ *{suEi) 



{suEi)\\ld{s2,E2) ->„ (4,-E'i)||lD'('^2,£'2) {si,Ei)\\ld{s2,E2) ->» {s[,Ei)\\ld{s2,E2) 

(PLDl) (PLD2) 

{si,Ei) —^o {s\,E\) \/ld G LD{p\ ; I ^ get jdominant Jabel[ld) /\p\ : I ^ get jdominated label{ld)) 

{s\,Ei)\\ld{s2,E2) ->„ {s\,Ex)\\ld{s2,E2) 

Figure 5: Operational Semantics of the Composition Language 

We define formally the functions used in the operational semantics. Function remove {1,LD) elim- 
inates the label dependencies which include / as first element from the label dependency set LD = 
{Idi, . . . ,ld,i}'- remove{l,{ldi,. . . ,W„}) = {ldi\ldjfzii „\ = (/i > I2) G {Idi,. . . ,ld„} Ali ^ 1} 

Transition {s\,Ei) —^o *{^ItE\) is equivalent to {s\,Ei) — >o * —^0-^0 *{si,Ei), where — >„ * represents 
any sequence of transitions — >„. This will determine if the label / belongs to a loop in transitions in a 
single protocol, starting from state s and ending in the same state s. Functions get jdominant Jabel and 
get dominated Jabel return respectively the dominant and dominated labels from a label dependency: 
get jdominant Jabel {{id : I > id' : I')) = id : I; get -dominated Jabel{{id : I > id' : I')) — id' : I' 

Next, we describe two algorithms to detect label dependencies in concurrent executions of protocols. 
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4.2 Dependency Analysis 

Dependency analysis is a technique to identify and determine data dependencies between service pro- 
tocols. The main difficulty in analysing dependencies for concurrent executions is how to obtain the 
relationship between arguments. Protocols evolving concurrently need to impose an order in their execu- 
tion if there exist data dependencies. A data dependency occurs when a protocol receives a data, which 
is stored in the user device, and when another client protocol accesses this data (e.g., wants to send it). 
To detect and handle these dependencies, our semi-automatic dependency analysis process consists of 
three steps: (i) a first algorithm computes a set of pairs of label dependencies between two protocols, 
(ii) the user makes a selection among these pairs and determines the order of execution of the selected 
ones (using the symbol ">"), which allows to build an initial label dependency set, and (iii) a second 
algorithm expands the dependencies chosen by the user to a set as required by the semantic rules PLD 1 , 
PLD2 and PLD3 formalised in Figure [5] 

The first step is performed by Algorithm [TJ that takes as input two protocols, and a domain ontology. 
It returns all the label dependencies among the argument types of the operation profiles of both protocols. 
Our algorithm determines that two labels are dependent by using the functions degree-match, defined by 
Paolucci et al. ll23l (page 339), and type to compare their arguments and types, respectively. Function 
degree-match defines four degrees of matching based on semantic matching: {exact , plugin , subsume , 
fail}. The degree fail indicates that the two arguments compared do not match semantically, so we do 
not consider that there exists a data dependency between them. The remaining three indicate that there is 
a semantic -based data dependency between the arguments. Function arguments in Algorithm [T] returns 

Algorithm 1 pairs JabeLdependencies 

returns a set of pairs of label dependencies for two protocols 

inputs protocols Pi = {Ai,S\,Ii,Fc\,T\) andP2 = (Al,S2,h,Fc2,T2), ontology Out 

output a label dependency set LDp 

1 : LDp :=% II initial value for set of pairs of label dependency 

2: for all Ipi e Ai do 

3: A/pi := argument s(lp I ) II gets the arguments of lp\ 

4: for all lp2 e A2 do 

5: A/p, := argument s{lp2) II gets the arguments of lp2 

6: ATD := false // by default no dependencies 

7: for all argip^ e A/,,, do 

8: for all argip^ e Aip^ do 

9: DMarg ■= degreejnatch{cu-gip-^,argip^ ,Ont) 

10: DM,yp := type(argip^ ) = type{argip, ) 

11: if {DMarg ^ f ai 1 ) A DM,yp then 

12: ATD := true // argument and type dependency 

13: end if 

14: end for 

15: end for 

16: if ATD then 

17: LDp := LDp U (pi : lp\,P2 '■ lp2) II adds a pair 

18: end if 

19: end for 

20: end for 

2 1 : return LDp II returns a set of pairs of label dependencies 

all the arguments belonging to a label / = {b,m,d,f): arguments((b,m,d,f)) = / 

The complexity of Algorithm [T] is quadratic, 0(k ■ (I ■ a)^), where ^ is a constant that indicates the 
number of dependent labels, and I and a are the average numbers of elements in labels and arguments, 
respectively. In the second step, the set of pairs of label dependencies returned by the previous algorithm 
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is showed to the user. The user selects the pairs of label dependencies he/she wants to preserve, and 
chooses the execution order for each pair. The result is a label dependency set. Given LDp = {{p\:l,p2: 
/'), {p\ : l,p2 '■ I")}, if the user: (i) only selects the first pair appearing in LDp, i.e. {p\ : l,p2 '■ I'), and (ii) 
indicates that I' has to be executed before I, then the result will be LD = {{p2 : 1' > pi : I)}. 

Last, Algorithm |2]takes as input the two protocols of Algorithm [Hand the set generated in the former 
step, and returns an extended label dependency set. The algorithm expands the set of label dependencies 
required by the semantic rules PLDl, PLD2 and PLD3. For each label dependency Id, the algorithm 
selects all the labels ;?/,,/ G {1, ... ,«} preceding the dominant label of Id in the coiTcsponding protocol. 
Then, for each /?/, the algorithm adds a new label dependency constituted by that plj as dominant label 
and the dominated label of Id as dominated label. For instance, given two protocols Pi with labels /, /' in 
sequence and P2 with /", if LD = {{pi : 1' > P2'- 1")} is the label dependency set obtained in the second 
step, then Algorithm |2] returns a new label dependency set LD^ = {{pi : I > p2- l"),{p\ : I' > p2- /")}■ 

Algorithm 2 extended JabeLdependencies 

returns an extended set of label dependencies from a label dependency set LD 

inputs protocols Pi = {Ai,S\,Ii,Fc\,T\) and P2 = (A2,S2,h,Fc2,T2), label dependency set LD 

output a label dependency set LD,, 



9 

10: 
11 

12 
13 
14 



LDg := LD II sets the extended set equal to LD 
for all Id £ LD do 

// := get.dominantJabel(ld) II gets the dominant label 

si := get .dominated Jabel(ld) II gets the dominated label 

Pf := get Jd.protocol{fl) II protocol id of dominant label 

Ps '■= getjd.protocol(sl) II protocol id of dominated label 

PL := get .previous Jabels(fl ,Tp, ) II gets the previous labels to the dominant label // in the transitions 7], , of its protocol pf 

for all plePLAo 

if {pf : pi > ps : si) ^ LD^ then 

LD,, := LDg U {pf : pi > ps : si) II adds a label dependency 
end if 
end for 
end for 
return LD,, II returns the extended set of label dependencies 



Function get Jd -protocol gets the protocol identifier of a label {id : /): getJd_protocol{{id : /)) = id 
Function get _previousJabels returns the labels preceding a label / in transitions T of a protocol: 

get .previous Jabels{l ,T) = {/'|El(i,_i,/,-,i,) G T A/ = {1, . . . ,n} A// = I' /\ln+\ = 1} 

The complexity of Algorithm |2] is linear, 0{ld ■ TPL ■ pi), where Id is the number of label depen- 
dencies, TPL the average number of transitions to check in the function get_previousJabels, and pi the 
number of labels preceding a concrete label. 

Example. Going back to our example, the Client wants to execute the protocol RC (route request) in 
sequence with the parallel execution of the protocols AC (music album request) and MC (museum ticket 
request): RC .{AC\\-ldMC) . Our approach builds the set of label dependencies between AC and MC. First, 
Algorithm [T] takes as input the two protocols, AC and MC, and the domain ontology presented in Fig- 
ure m It returns a set of pairs of label dependencies between AC and MC: LDp = { {lac^ , hnc^ ) , {hics > hncs } 
(protocol identifiers in labels have been removed), since for the checkAccount operation profile in both 
AC and MC, currentAccount exact matches account, and for bankBalance, balance is semantically 
compatible to credit, with degree of match plugln. However, for instance, for reqAlbum and reqMu- 
seum of AC and MC respectively, the degree of match of arguments and types is fail, since although 
priv exact matches priv, album fail with respect to museum. Then, the resulting set is given to 
the user, who selects the pairs of label dependencies he/she wants to preserve, and chooses the exe- 
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cution order for each pair. Let us suppose the user only selects the pair {l^^^ , l,„c^ ) to control the con- 
cun^ent execution of the operation checkAccount in both AC and MC, by executing lacj, before Z„,c^: 
LD = {(/flC4 > Imc^)}- Last, Algorithm |2] takes LD as input and extends it with new dependencies needed 
to execute the semantic rules PLDl, PLD2 and PLD3. Thus, we obtain the final label dependency set: 
LDe = {(/„,., > Lc^),{lac2 > lmc^),{laci > lmc^),{lac^ > hn^)}- This mcans that, e.g., for {laci > Imc^), 
laci is executed before /„,C4, i.e., the label AC : laci = reqAlbumlalbum, priv is executed before the label 
MC : lmc4 = checkAccount [account , and so on. In such a way, the algorithm controls that 1^04 will not be 
executed in MC until AC runs /ac4 ■ 

4.3 Verification of Label Dependencies 

The label dependencies construction process is error-prone, since it requires human intervention. This 
process may provoke possible inconsistencies which result in deadlocks during the execution of the 
protocols according to the label dependency set computed previously. Therefore, in this section we 
propose some verification techniques to automatically detect these problems. 

To illustrate the need of these verification techniques, we focus on a simple example. In Figure [6l we 
give, e.g. , Client's Planning and Hotel protocols, PC and HC respectively. The Planning protocol requests 
for a travel plan to a specific address, and receives a map of the area close to that address. The Hotel 
protocol searches for a hotel in that map, and gets the destination address. By applying our dependency 
analysis. Algorithm [T] first returns the pairs of label dependency: LDp = {(Zpi,,//^^), (Ips^Jhsi)}- Second, 
let us suppose the result of the user selection is: LD = {{Ihsn > lpsi),{lps2 > hisi)}- Last, the extended 
label dependency set is: LD^ = {(//«i > Ips^), {hm > lpsi),{lpsi > ksi),{lps2 > hsi)}- In this set, the two 



Client 



Planning Protocol {PQ 

Ips i=reqMap ! address 

•-•# — ■ »€)- 



lps2=recMap ?map 



Hotel Protocol (HQ 

Ihsi =searchHotel !map 

K© »^ 



lhs2=getAddress ?address^ 



Figure 6: Client's Planning and Hotel Protocols Executing Concurrently 

label dependencies (//„, > /;„,) and {Ips^ > l^si) provoke a deadlock, since they are in mutual exclusion. 
The two (crossed) label dependencies {lhs2 > Ipsi ) and {lps2 > hsi ) also generate a deadlock, since the 
Planning protocol cannot start without the address and neither the Hotel protocol without the map. The 
user will be informed to remove one of the label dependencies which provoked this deadlock situation. 

Algorithm [3] takes as input two protocols and their label dependency set, and returns a set of traces 
(pairs of label dependency) leading to deadlock states. To do that, the algorithm compares all the domi- 
nant labels from the label dependency set with the dominated ones. If for two label dependencies, a same 
label is dominant and dominated in both directions or there exist crossed dependencies as described 
above, then there is a deadlock situation. This problem has to be notified to the user in order to let 
him/her modify the selection or execution ordering of the label dependencies to avoid that inconsistency. 

The complexity of Algorithm [3] is quadratic, 0{ld^ ■ TPL), where Id indicates the number of label 
dependencies, and TPL is the average number of transitions to check in the function get_previousJabels. 

Example. For the scenario of our case study, we applied Algorithm [3] and checked that no problems 
exist in the label dependency generated in Section l4!2l since there is no trace (pair of label dependency) 
that provokes a deadlock mismatch when executing concurrently both protocols AC and MC, i.e., LD^ = 
0. Therefore, our label dependency set is correct. 
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Algorithm 3 label_dependency_verification 



detects possible inconsistencies specified in a label dependency set 

inputs protocols Pi = {Ai,S\,Ii,Fc\,Ti) and P2 = (A2,S2,h,Fc2,T2), label dependency set LD 

output a deadlocked label dependency set LD^i 



1 : LDii :=</>// initial value for set of pairs of deadlocked label dependency 
2: tor all Id peLD do 

3: fldp := get. dominant Jabel{ldp) II gets the dominant label 
4: sldp := get. dominated J abel(ldp) II gets the dominated label 
5: PfUp '■= get Jd.protocol(fldp) II protocol id of dominant label 
6: for all Idg e LD do 
7: ifWp^Wgthen 

8: fldg := get .domitiant Jabel{ldg) 

9: sldg := get dominated Jabel{ldg) 

10: P//rf? ■= get Jd_protocol[fldg) II protocol id of dominant label 

11: end if 

12: if {{fldp == sldg) A [sldp == fldg)) 

\/{sldg€get_previousJabels{fldp,Tp„j^)Asldp £ get.previousJahels{fldg,Tp„j )) then 
13: LDj := LDii U (Idp, Idg) II adds the pair of deadlocked label dependencies 

14: end if 

15: end for 
16: end for 
17: return LDj II returns the set of pairs of deadlocked label dependencies 



5 Tool Support and Experimental Results 

5.1 Tool Support 

Our approach for handling concurrency of context-aware service protocols, has been implemented as part 
of a prototype tool, called ConTexTive, which is integrated into our toolbox ITACA IH. ConTexTive 
has been implemented in Python with the purpose of being incorporated inside a user device. It aims 
at discovering services related to a client request and handling the service composition by means of 
our composition language. We have implemented the algorithms presented in this work, in order to 
automatically detect data dependencies and check that deadlock situations do not occur when executing 
protocols concurrently. Figure |7] gives a tool support overview of how our approach has been encoded. 
Our approach takes client and service interfaces specified as XML CA-STSs, and an XML ontology of 
a specific domain as input, and detects a label dependency set {LD) for each pair of protocols executing 
concuiTcntly, and checks if this set is consistent (free of deadlocks). 



XML files I- Interface Model : 
Client's requests 



ConTexTive 

Handling Data -Based Concunency in Context-Aware Sen/ice Protocols 



Interface Model : | XML files 
Available Services 



Context Profile 
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Di 



Service Monitoring Engine (SME) 



CA-STS Protocol 



§C 



I Label Dependency (LD)^I Verification of LD 



Context Profile 

I - 

Signature I 

i — 



CA-STS Protocol 



modify LD^— deadlock 



Figure 7: Tool Support Overview 



ConTexTive has been validated on several examples, such as an on-line computer material store, a 
travel agency, an on-line booking system or the case study presented here: a road info system. 
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5.2 Experimental Results 

We have conducted a small experimental study with the assistance of a group of volunteers. This study 
helped us to determine how our approach behaves in terms of evaluating the benefits to find out data 
dependencies in concurrent executions and to handle those dependencies in terms of effort required, ef- 
ficiency and accuracy of the dependencies detected. Users performed tests either in a manual or in an 
interactive (using the tool) way. In order to perform the tests, we provided them a graphical representa- 
tion of the interfaces and a specific domain ontology to be used in the concurrent interaction, for each 
problem. Each user solved different problems using different specifications (manual or interactivo to 
prevent previous user knowledge of a particular case study. Table [T] shows the problems used for our 
study, which are organised according to increasing size and complexity with respect to the number of 
interfaces (client and services) involved and the ontology, as well as the overall size of cUent protocols as 
a total number of states and transitions. Tests considered all the client protocols interacting concurrently. 
The table also includes the comparison of experimental results using both manual and interactive spec- 
ification of data dependencies and their coiTcsponding execution priorities. We consider as parameters 
the time required to solve the problem (in seconds), the number of label dependencies detected (Depend, 
in Table [T), and the number of errors in the specified data dependency set. 



Problem 


5 


ize 


Parameter 


Interfaces 


Client Protocols 


Time(s) 


Depend. 


Errors | 


Client 


Services 


States 


Transitions 


M 


I 


M 


I 


M 


I 


pc-store-v02 


2 


2 


10 


8 


61,80 


19,14 


1 


3 


2 





ebooking-v04 


2 


3 


12 


13 


51,60 


3,17 


1 


1 








roadinfo-v06 


3 


3 


16 


18 


113,62 


16,51 


5 


4 


3 





travel-agency-v04 


3 


5 


36 


36 


271,84 


62,38 


12 


12 


4 






Table 1 : Experimental Results for the Manual (M) and Interactive (I) Specifications 

As it can be observed in the results, there is a remarkable difference in the amount of time required 
to solve the different problems between manual and interactive specification. We measure as errors the 
number of wrong, unnecessary or non-detected label dependencies. Our tool always detects all the data 
dependencies and it uses semantic matching to determine those dependencies, so this is a clear advantage, 
which increases with the complexity of the problem, compared to the manual specification. Thus, the 
time elapsed for detecting dependencies by using our tool experiences a linear growth with the size of 
the problem. Therefore, scalability and performance of our tool are satisfactory, and in the worst case 
(ti"avel-agency-v04) the time required is roughly 1 minute, which is a reasonable amount of time. 

6 Related Work 



This section compares our approach to related works by emphasising our main contributions. We succes- 
sively describe works related to service models by using protocols and/or context information, and works 
focusing on monitoring of service composition to detect data dependencies in the protocol interaction. 

Context-based protocol models address the design and implementation of applications which are 
able to be modified at the behavioural interoperability level depending on context information. Not 
many works have been dedicated to model context-aware service protocols. Braione and Picco fVl have 



^The scenarios were executed on an Intel Pentium CPU 3GHz, 3GB RAM, with Microsoft Windows XP Professional SP2. 
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proposed a calculus to specify contextual reactive systems separating the description of behaviours and 
the definition of contexts in which some actions are enabled or inhibited. Related to context-aware adap- 
tation, Autili et al. |3| present an approach to context-aware adaptive services. Services are implemented 
as adaptable components by using the CHAMELEON framework lH. This approach considers context 
information at design time, but the context changes at run-time are not evaluated. In our approach, we 
propose a model to specify protocols based on transition systems and extended with value passing, con- 
text information and conditions, which has not been studied yet in previous works. We consider context 
changes not only at design-time, but also at run-time, since our model allows the continuous evaluation 
of dynamic context attributes (according to the execution of the operational semantics). 

As regards concurrency, models for this discipline emerged, such as CSP |[T5l and CCS fT9||, which 
address concurrent systems from an algebraic perspective. The ;r-calculus ||20ll builds on CCS as a 
process algebra for communicating systems that allows expression of reconfigurable mobile processes. 
Related to service concurrency, recent approaches have been dedicated to the interaction of services at 
run-time with the purpose of composing correctly their execution. In addition, several works describe 
different ways to present data dependencies according to their use for different purposes. Vukovic ll25l 
presents an approach that focuses on the recomposition of the composite service during its execution, ac- 
cording to changes in the context. It provides a failure-tolerant solution, but user preferences and control 
of independent requests are not controlled, whereas our model supports that. Mrissa et al. |[22l present 
a context-based mediation approach to solve semantic heterogeneities between composed Web services 
by using annotation of WSDL descriptions with contextual details. Their architecture automatically gen- 
erates and invokes service mediators, so data heterogeneities between services are handled during the 
composition using semantics and contexts. These works do not handle data dependencies during the 
concurrent execution of service protocols. Basu et al. |3 model such dependencies using a directed 
edge between nodes. They generate a probabilistic dependency graph as concatenation of all identi- 
fied dependencies. Ensel |[T4i presents a methodology to automatically generate service dependency 
model considering the direction of dependencies. In ifTTl . Kuang et al. give a formal service specifi- 
cation describing two types of dependency: dependency on assignment (between the input and output 
interfaces of an operation), and dependency on sequence (order among operations of a service). Yan et 
al. |[26l . propose an approach to discover operation dependencies using semantic matching of input and 
output interfaces and the invoking order among operations. They construct frequency and dependency 
tables in order to derive indirect dependency relationships by transitive closure algorithm. Most of these 
approaches do not consider a combination of both the directionality and the execution order to detect 
dependencies. To the best of our knowledge, the only attempt taking both restrictions into consideration 
is |[26l . Compared to these related works, our approach does not only detect data dependencies, address- 
ing both direction and order, that appeared between communications, but it also allows context-aware 
protocol concurrent executions at run-time by means of our composition language. In addition, in order 
to analyse dependencies we rely on semantic matching techniques between data. 



7 Concluding Remarks 

In this paper, we have described a model to formalise context-aware clients and services. We have also 
proposed a composition language to handle dynamically the concurrent execution of service protocols. 
We have defined algorithms to detect data dependencies among several protocols executed on the same 
user device. These algorithms make possible to establish some priorities on the concurrent execution of 
protocols affected by these dependencies. In this way, our approach allows to maintain data consistency, 
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even if a parallel change occurs at run-time. Last, we have proposed verification techniques to automat- 
ically detect possible inconsistencies specified by the user while building the data dependency set. We 
have implemented a prototype tool, ConTexTive, which aims at handling the concurrent interaction of 
service protocols at run-time. Our approach focus on mobile and pervasive systems. 

We are currently working on avoiding the human intervention in the process of building the data 
dependency set by means of priorities previously defined. This will allow to determine automatically the 
execution order of the detected dependencies, reducing the time required in the interactive specification. 
We ai^e also extending our approach to solve other problems arisen in the context-aware service compo- 
sition, such as exception or connection loss. As regards future work, our main goal is to incorporate our 
prototype tool inside a user device in order to support concurrency in real-world applications running on 
mobile devices. We also plan to extend our framework to tackle dynamic reconfiguration of services, 
handling the addition or elimination of both services and context information. In addition, we want to 
include the repetition operators in our composition language, and to handle concurrent execution of more 
than two protocols by detecting at the same time all data dependencies existing among several protocols. 
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